Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1162

Internet Message Format | 1994-08-27 | 14KB

Date: Sat, 30 Jul 1994 16:52:42 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: Digest
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407301642.A26054-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Evan:

]Its a bug in the AES.  I get it too.  Sometimes, I just get clicks with
]background windows instead of a top.  I get it in TOSWIN alot, which is
]when I have lots of windows open, so that could be part of it.  I just
]jam the mouse into the menu bar and then click (since I usually have
]window everywhere, and the menu bar is the only place uncovered!)

If my guess is correct, then it is not a bug in AES.  Rather,
graf_dragbox and form_button use evnt_multi!  And since evnt_multi
obviously will not send repeated WM_TOPPED messages to the same window
while the mouse is held down, then graf_dragbox and form_button will not
work.  graf_mkstate, on the other hand, works just great.

]Your solution .. you said you were simulating mouse events.  How did
]you do this.  I wanna see how much it changes the code I posted previously.
]Since the code I posted allowed some pretty radical behavior (the use
]of the other mouse buttons during a drag!) and I don't want to lose
]that flexibility.  In fact, I don't want to call any graf_ functions
]or anything else that creates a mode.  I want to flow everything though
]evnt_multi() with an optimized binding (no stack usage, etc) and doll
]out the events to other objects from there.

My solution was to write my own form_button which does nothing
spectacular.  It just does everything that the normal form_button (took
me a lot of guess work, but I can't tell any difference between mine and
the normal one), except that mine will work even if the object is
partially obscured.

Writing my own form_button solved the problem of it locking up.  The
second problem was to get repeated mouse events to a background window.
Since evnt_multi win't sent repeated WM_TOPPED messages, I have to handle
everything after I get the first one, *plus I have to make sure the mouse
button it up before the next evnt_multi call*.

I have one routine that handles WM_TOPPED events, and another that
handles MU_BUTTON events.  When I get a WM_TOPPED message for a
background window that is 'backactive', I get the current mouse position
and other information and send it to my routine that handles the
MU_BUTTON events, thereby simulating a button event on the background window.

To do drags and to make sure that the button is up before the next
evnt_multi (when my WM_TOPPED handling routine returns to the caller), I
have a loop in my WM_TOPPED handler that keeps getting mouse positions
and information as long as the button is held down.  As soon as the
button is let up, it returns to the calling routine.

This works great.  The only problem is that while the button is down, the
operations of my library are trapped within itself, not getting back to
evnt_multi.  But since you can't use evnt_multi anyway, there's no point
in arguing about it.  However, since my library doesn't use wind_update
(since it's not using VDI, it doesn't need to, plus a developer is
responsible for doing it for his own window drawing, PLUS since you're
dragging around in a window, you couldn't move the mouse pointer to the
menu bar to fowl anything up), no activities in other windows would be
bothered with much.


]========================================================================
]Well, I break my library down into a few seperate .C files and the
]programmer can pick which ones he wants.  I'm sure that's what most of
us do.
]========================================================================
]
]Nope, you put EVERY function in a separate C file, roll the whole thing
]into a .a or .lib or what have you, and then whatever functions the
]programmer uses will be included by the linker.  The linker includes
]entire .o files, so the programmer doesn't choose, the LINKER chooses.
]This requires libraries to have TONS of files.  Makes a MINIX filesystem
]very handy, but that is beside the point.

Sounds icky, but I'll see what I can do.  I think, though, I will cut it
up after I'm done.

But there is one thing I need to mention... some of my functions use
other functions that only THEY use and are not needed to be accessed from
any where else.  Should I put them into the same O file?

How do I create an A or LIB file?  What is the difference between the
two?  I've never looked into this before.



About app-defs:

AVOID scancodes it the app-defs file.  It's easy enough to tell the
difference between Backspace and Ctrl-H (or Return/Enter/Ctrl-M, etc...)
regardless of where H is because while H may move, Backspace won't and
Ctrl-H is then just any key that produces an ascii code of 7 what ISN'T
the Backspace key.  It's quite simple.  Therefore, only specify ASCII
codes in the app-defs file for the letter keys.  Anything else like
Return, Enter, Backspace should, however, be referenced by scancode.
Plus, it's safe to do that because THEY don't move.


Oh, and there's another problem with app-defs... if you don't have a TSR
to load it (of course translate it into something useful) and put it in
one place in memory, then you'll have every app with its own copy of the
file.  On the other hand, the TSR creates a load of its own problems, not
the least of which is the fact that the app is going to have to figure
out whether it should use the default key or determine if the user's put
one in there to customise it just for that app.


]Huh?   No, no, no.  Like this:
]
]*.*.autoSave.yes
]*.*.confirmAtExit.yes
]*.YourApp.autoSave.no
]*.TosWin.autoSave.no
]
]Get it?  Now everything but YourApp and TosWin will autosave.  Everything
]confirms at exit.  You can still manually save.  You don't have to change
]anything.  In fact, the file is pretty static.  You only need to change
]it to change global settings or to change a specific application to do
]something different than the global settings you've installed.  You edit
]less because if you turn off a global feature, that program you haven't
]used in 3 months doesn't have to be reconfigured!

I don't like this particular example.  There are some things that you
MIGHT want to configure in a global file, but auto-save isn't one of
them.  IF an app has auto-save, I would think that it should keep track
of it in its OWN config file.


Everyone seems to be bent on making the app-defs file an ASCII file.
While I can see the clear benefits (user editable with an ASCII text
editor, etc.), I can see some clear draw-backs.  If it's an ASCII file,
any utility manipulating it will have to delete it and write a new one
any time a change is made because the size of the file would change
(although this isn't much of a big deal), plus it's harder to parce
(because if it's binary data, you don't have to parce at all!).


Evan:

]Thread2 - this waits on any number of file handles, although it only
]needs to wait on one (optional timeout).  It blocks until the
]device is has data ready to be read or written.  When Fselect returns,
]Fread as much data from the file handle (raw mode) as you can,
]with standard GEMDOS Fread() with a whatever maximum you like (you
]can use whatever you like, or dynamically change the size if Fread
]reads your entire buffer, then double the size so it doesn't fill
]up anymore!)  After you read all the data, update your windows
]internal and external structures.  Key events are still echoed
]directly to the modem, even during redraw.  Once you've done the
]update, call Fselect again and wait for more modem data.  This thread
]will block when there is no modem IO to read.

This sounds very interesting.  I'll have to figure out Fselect.
One problem I have with modem I/O is that GEMDOS does not seem to provide
a way for me determine how many characters are there before using Fread.
As a result, I have to use Fread (or Bconin) repeatedly, reading one
character until Bconstat says there are no more characters.

I have a couple or routines that read directly from the Iorec